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ADS OVERVIEW 

THE ADS PROJECT - continued 


CHARTER 

To Provide current and future generations of space scientists with direct, 
on-line access to existing and future multispectral data and analysis tools. 


OBJECTIVE 

The ADS is a production level distributed processing system. The Objective 
of the ADS is to make all science data holdings and all ADS Hardware and 
Software services available to all users transparently. 


OVERVIEW of the ADS 


Architectural Approaches 


o The "rlogin" model 

- User accesses each site independently 

- User must have accounts everywhere 

- Tools and interfaces are generally site specific 

- Data Transfer is done in a different environment 

o The Client / Server Model 

- Global Uniformity 

- Standard Interfaces 

- Modularity 

- Separation of Processing and User interface 

- Easily incorporates existing services 

- Easily expanded and evolved 

- Location independence (of user, data, and processing tools) 



OVERVIEW of the ADS 


Elements of the Solution 


o User Interfaces 
o User Services 

- Distributed Access to Existing Database Systems 

- Document Location and Retrieval 

- Local Table Manipulation 

- Local Visualization 

o System Services 

- User / Service Authentication 

- Help 

o Glue 

- NASA Science Internet 

- Message Passing Service 

- Standard Data Formats and I/O 
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ADS OVERVIEW 


ELEMENTS OF THE SOLUTION - SQL SERVER 


o Heterogeneous DBMS's 

- Relational 

- Heirarchical 

- Network 

o Distributed Interaction 
o Homogenization and Translation 


ADS OVERVIEW 

ELEMENTS OF THE SOLUTION - FACTOR SPACE 


o Failure of the "Library" Model 
o Personal Perspective 
o Fields and Terms 


o Factor Spaces 
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ADS OVERVIEW 


DEVELOPMENT AND OPERATIONS PHILOSOPHY 


The ADS was designed and built by practicing astrophysicists for practicing 
astrophysicists. 

Utilizing the most advanced commercially available and supported 
distributed processing system technology, it is specifically designed to meet 
the evolving needs of the professional scientist and to provide the community 
with a powerful and immediately useful research and educational facility. 


ADS OVERVIEW 


STATUS 


PHASE ONE: 

At present, data holdings from SAO and IPAC are accessible using advanced 
remote procedure call and other advanced distributed processing system 
techniques. Over the next three months, data holdings from IUE/GSFC, 
IUE/CASA, STScI, Penn State, and the NSSDC will be added to the system. 
Data holdings from all great observatory and explorer class missions will be 
added as available. 


PHASE TWO: 

Provide on-line access to existing and future data analysis and manipulation 
tools to include imaging/visualization, graphic analysis, statistical, and such 
other tools as deemed appropriate by the user community. These tools will be 
made available as distributed processed to maximize compute and software 

resource availability to the community. 
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o System Generated Services 

- Transaction Management 

- System Monitoring 

- System Interfaces 

- User Interfaces 

- Communications Services 

o User Generated Services 

- Data Analysis 

- Visualization 

- Modeling 
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ADS OVERVIEW 
THE FUTURE - continued 


o Project Generated Services 

- Planning and Scheduling 

- Monitor and Control 


o Datasets 


- linages 

- Spectra 

- Ground - Based Data 

- Textbooks and Journals 
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OVERVIEW OF THE ASTROPHYSICS DATA SYSTEM 


John C. Good and Richard B. Pomphrev 
Infrared Processing and Analysis Center 
Jet Propulsion Laboratory 
California Institute of Technology 
Pasadena, CA 91125 

Abstract 


The Astrophysics Division of NASA has built a geo- 
graphically- and logically-distributed heterogeneous in- 
formation system for the dissemination and coordinated 
multispectral analysis of data from astrophysics missions. 
The Astrophysics Data System (ADS) is a truly dis- 
tributed system in which the data and the required pro- 
cessing are physically distributed. To accommodate the 
anticipated growth and changes in both requirements and 
technology, the ADS employs a server/client architecture 
which allows services and data to be added or replaced 
without having to change the. basic architecture or in- 
terfaces. Current datasets accessible through the system 
include all the tabular astronomical data available at each 
of six existing astrophysics data centers. Additional data 
nodes, at both NASA data centers and academic insti- 
tutions, will be added shortly. The future evolution of 
the system will be driven in large part by user services 
mounted both by the ADS project itself and by members 
of the astrophysics community. 

Astrophysics Data System Philosophy and Strategy 

Astrophysicists today have a bewildering array of 
powerful NASA resources to call upon. Among these are 
the data centers for the High Energy Astrophysics Ob- 
servatories (HEAO’s), the International Ultraviolet Ex- 
plorer (IUE), the Infrared Processing and Analysis Center 
(IPAC), and the Hubble Space Telescope Science Insti- 
tute (STScI), as well as the National Space Science Data 
Center (NSSDC). Unfortunately, the services provided by 
these centers are essentially independent and some are 
only accessible through mission- unique hardware and soft- 
ware. Furthermore, they can generally only be accessed 
directly through the centers themselves. 

The Final Report of the Astrophysics Data System 
Study, March 1988, characterized the data environment of 
the Astrophysics community at that time and defined for 
the future an u . . . architecture for a data system which 
will serve the astrophysics community in multi-spectral 
research through the decade of the 1990’s.” One of its 
recommendations was that each data set, and the hu- 
man expertise which supports the data, be maintained 
at the same physical location. Moreover, these multiple 
locations should be linked together and to researchers by 
means of high speed communications networks. Finally, 
to allow true multi-spectral research the various data sets 
should be accessible through a common set of tools. 

The Astrophysics Data System (ADS) Project is 
NASA’s response to the Data System Study. For the sci- 
ence investigator, the ADS makes NASA’s current and fu- 
ture data holdings more broadly and efficiently accessible, 
and makes the data itself more interpretable. For NASA, 
it provides a common information system infrastructure 


for science analysis, thereby reducing duplication of effort 
while increasing the scientific return from missions. 

The ADS is a truly distributed system in which 
both the data and the required processing are physi- 
cally distributed. To accommodate anticipated growth 
and changes in both requirements and technology, the 
ADS employs a server/client architecture which allows 
services and data to be added or replaced without having 
to change the basic architecture or interfaces. The ADS 
design is modular and layered, enabling smooth evolution 
of the hardware and software without interruption of ser- 
vice to the user community. In addition, the ADS will 
provide all on-line information necessary to use the ADS 
services and data; and its design enables remote updating 
of the software services. 

ADS Software Architecture 

Conceptually, the software can be divided into two 
categories. Core Services are those which provide the ba- 
sic system functionality upon which user applications or 
User Services can be built. These will be built primarily 
by the ADS Project itself. User Services are other ap- 
plications which reside on the ADS and provide science 
support and analysis functions required by the investi- 
gator. These may be built by the Project in response to 
community demand or by individuals or groups funded by 
the NASA Astrophysics Science Research Aids (ASRA) 
Program. 

In its initial release, the ADS will provide basic Core 
and User Services. These will be expanded and supple- 
mented in the future based on feedback from the Astro- 
physics community. 

Initial Core Services 

The MESSAGE PASSING SERVICE (MPS) enables 
remote inter-operability and data transfer/translation 
among the ADS services. It provides homogeneity across 
networks and operating systems for process requests and 
responses. While this service is largely invisible to the 
end user, it provides the application programmer (and the 
ADS system programmers) what the User Interface pro- 
vides for the science end user: an environment in which to 
access the services of the ADS from within an application 
program without knowing which servers will execute the 
program or the services it accesses. At a minimum, the 
MPS implements the functionality of: 

- Remote Procedure Call (RPC): a mechanism by 
which the subroutines of a program can call each 
other as if they were executing on a single server 
when, in fact, they may be segmented across several 
servers; 



- Remote Process Invocation (RPI): a mechanism by 
which a program on one server can spawn programs 
on other servers; 

- Remote Inter-Process Communication (RIPC): a 
mechanism whereby two or more programs running 
concurrently on different servers can communicate 
among themselves. 

In the initial release, the ADS Message Passing Ser- 
vice conforms to the Advanced Network System Architec- 
ture Testbench (AN SAT) and the Open Software Founda- 
tion/Distributed Computing Environment (OSF/DCE). 

USER INTERFACES are the services which provide 
the local working environment (including its look and feel) 
to the end user. As such they provide a means to access 
all other services within the ADS. The structure of the 
ADS is such that there can be any number of user in- 
terface programs incorporating the constraints, hardware 
limitations, and preference of specialized segments of the 
community. Our efforts to date have concentrated on a 
single user interface which is structured to conform to a 
“least common denominator” hardware environment, and 
which provides an effective interface to the initial set of 
ADS Services. The ground rules have been: 

- the ADS system must be accessible using any charac- 
ter terminal supportable under the UNIX “termcap” 
facility (basically any display with 24x80 characters 
and an addressable cursor); 

- the ADS system must be effective (if slow) at 1200 
baud. 

- it must be possible (but not required) to configure the 
system such that the user interface and appropriate 
interactive processing is done at the user’s site, rather 
than at centralized facilities. 

- the user interface in particular should be available 
under UNIX, VMS and MS/DOS. 

Even with these constraints, we are able to provide an 
ADS User Interface that prorides the following combined 
functionality: 

- specialized table display and interactive manipula- 
tion facilities; 

- a first-order complete relational database facility 
including support for Structured Query Language 
(SQL) and Query by Example (QBE); 

- Menu bar/pulldown menus and multiple windows 
(split-screen); 

- context-sensitive help and a dynamic tutorial facility; 

- full-featured text management facility that supports 
browsing, plain-text inquiry and cut-paste editing of 
selected files. 

Through this interface, investigators can locate data 
sets (descriptions and catalogs) of interest, access these 
data sets either individually or in combination, and select 
from among them one or more subsets that they wish to 
import into a local working environment for further analy- 
sis of their own choosing. More importantly, it allows the 
investigator to accomplish this without requiring him to 
know which servers execute the services he invokes. In the 
initial release, the Knowledge Dictionary System (KDS) 
(tm) is being used to implement the functionality of the 
User Interface. 

The DATA INDEPENDENT ACCESS MODEL 


(DIAM) is a service which provides inter -operability 
and language conversion among the various distributed 
Database Management Systems (DBMS's) in the ADS. 
These DBMS's include the following: Ingres and Sybase 
(UNIX), RDB (VMS), and IM/DM (CDC NOS/VE). The 
DIAM is required in the ADS in order to provide the user 
with a uniform relational view of all these distributed cat- 
alogs even though some of the catalogs axe still maintained 
using DBMS’s that do not yet support the relational SQL 
standard. The functionality of the DIAM is: 

- to accept SQL statements generated by the User In- 
terface (either directly or indirectly using the QBE 
translator); 

- to convert them to the language supported by the 
DBMS that hosts the referenced catalog(s); 

- to RPI a process to submit them to the DBMS for 
processing and to collocate the resulting table(s); 

- to return those results to the User Interface that is- 
sued the request. 

The Distributed Access View Integrated Database 
(DAVID) system is being used to implement the func- 
tionality of the DIAM. 

Besides providing uniform access to the multiplicity 
of existing DBMS’s, DAVID provides a complete inter- 
nal distributed DBMS which allows further processing 
with special features not available in most commercial 
DBMS’s. Of particular importance in a distributed en- 
vironment is its ability to allow dataset browsing. This 
minimizes the overhead potentially incurred by having to 
transfer data in large chunks around the country. 

Future Core Services 

There are several Core Services which axe important 
and anticipated in the near future, but which were not in- 
cluded in the initial release of the Astrophysics Data Sys- 
tem. Among these are the User/Service Authentication 
Service and the Transaction Management Service. Other 
Core Services will be added on as they are required and 
become available. 

The USER/SERVICE AUTHENTICATION SER- 
VICE will provide the capability to automatically verify 
the authorization of a user to access the ADS System and 
to access specific services and data within the system. It 
will be provided through an implementation of the KER- 
BEROS software on the ADS System. 

The TRANSACTION MANAGEMENT SERVICE 
(TMS) will provide the process and resource management 
protocol for client-defined transactions. It assures suc- 
cessful execution, synchronization, and release of all ser- 
vices and resources used in a transaction. The TMS pro- 
vides two basic functions: 

- insure, without further client intervention, that all 
the services requested during a transaction will be 
successfully executed even if some of those services 
or the servers on which they are executing fail while 
the transaction is in progress; 

- insure, without further client intervention, that all 
resources involved in a transaction are properly syn- 
chronized and released regardless of the destiny of 
the transaction (success or failure). 
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The TMS is both an optional and a passive service; 
optional in that it mus; be explicitly invoked by the client; 
and passive in that, as a peer-to-peer system, there is no 
mechanism by which the TMS protocol can be enforced, 
and the only programs that are guaranteed to participate 
in the TM protocol are the core services of the ADS. To 
encourage the use of the TM by end-users and applica- 
tion programmers, the protocol has been kept as simple 
as possible, requiring only four commands: Begin, Lock, 
Upgrade, and End. 

Begin is a signal that a program is starting and re- 
turns a unique Transaction ID that the program must 
use in all subsequent calls to the TM. Lock signals the in- 
tent of the program to access the resource (e.g., a record 
in a file) named in the call. Upgrade signals the intent 
of the program to modify a previously Locked resource. 
End signals that the program is terminating, and the 
mode of termination (success or failure). For the initial 
ADS release, the components of the Transaction Manage- 
ment Service are implemented by the Transaction Man- 
ager (tm), which is an integral part of the Knowledge 
Dictionary System (tm). The TMS components will be 
exported as discrete services through the Message Passing 
Service through which they will be accessible by Remote 
Procedure Calls. 

Initial User Services 

The initial User Services available through the ADS 
have usually been collectively referred to as Directory 
Services, with components that provide access to cata- 
log data and to documentation about data holdings for 
specific Astrophysics archives, without requiring the user 
to know where the data physically resides. These Direc- 
tory Services include Document Retrieval, Documenta- 
tion Browse, and a Catalog Data Retrieval and Processing 
Service. Astrophysics data comes in several forms (e.g., 
catalog data, spectral data, image data). The initial re- 
lease of the ADS will be limited to catalog data (though 
some of the catalogs are in fact lists of images or spectral 
observations). 

The DOCUMENT RETRIEVAL SERVICE provides 
uniform, subject-matter indexing (and English-language 
querying) across all the data in the ADS, regardless of 
whether data are highly structured in databases, or un- 
structured. For the initial release, the Document Re- 
trieval Service is implemented by the Factor Space Ac- 
cess Method (tm) as an integral part of the Knowledge 
Dictionary System (tm). The various components of the 
Document Retrieval Service will be exported as discrete 
services through the Message Passing Service, through 
which they can be generally accessed by Remote Proce- 
dure Calls. 

The Factor Space (FS) is an n-dimensional Euclidian 
space, the axes of which are statistically constructed to ac- 
count for the variance and covariance in expert judgments 
made by astrophysicists about the relevance of ADS data 
items to different subject matter contexts. The functions 
of the Document Retrieval service are: 

- to scan all data entered in the ADS and compute its 


subject matter profile as a sequence of one or more 
vectors in the Factor Space; 

- to similarly analyze natural language requests and to 
search the Factor Space for relevant data items; 

- to monitor the distribution of vectors in Factor Space 
for clusters (i.e. , undifferentiated data items); 

- to periodically generate, disseminate, collect and syn- 
thesize questionnaires to obtain additional relevance 
judgments needed to increase the data resolution; 

- to factor- analyze these additional relevance judg- 
ments and modify the number and/or orientation of 
axes in the Factor Space accordingly. 

These functions also support the generation of new 
Factor Spaces, either to accommodate new subject matter 
or to accommodate personalized perspectives on existing 
subject matter. 

The DATA BROWSE SERVICE provides a simple 
means for users to access and organize directories and files 
through the functionality of the User Interface described 
above. 

The DATA RETRIEVAL AND PROCESSING SER- 
VICE provides the capability to retrieve cataloged data 
and perform data base management processing on that 
data through the query, text management, and relational 
data base functionaditv of the DIAM and User Interface 
services described above. 

Future User Services 

It is expected that other User Services will be made 
available as they are requested by the Astrophysics user 
community and integrated into the ADS. Because of the 
flexible modular nature of the ADS architecture, such in- 
tegrations should be relatively straightforward and can be 
implemented in a variety of ways, dependent on how the 
prospective User Service is coded. These new services can 
be derived from any of the following sources: 

- Astrophysics Science Research Aids (ASRA) Pro- 
gram 

- NASA Astrophysics Flight Projects 

- Other NASA Flight Projects 

- Other NASA Programs 

- Non-NASA Programs 

- Non-US Programs 

ADS Physical Architecture 

An overview of the ADS physical architecture is pre- 
sented in the figure below. In its initial instantiation, 
the ADS will consist of six physically distributed primary 
nodes which are interconnected via NASA Science Inter- 
net (NSI). These six nodes are the following: 

- Center for Astronomy and Space Astrophysics 
CASA), Boulder, Colorado 

- Infrared Processing and Analysis Center (IPAC), 
Pasadena, California 

- International Ultraviolet Explorer (IUE), Greenbelt. 
MaLryland 

- National Space Science Data Center (NSSDC). 
Greenbelt, Maryland 
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- Smithsonian Astrophysical Observatory (SAO), 
Boston, Massachusetts 

- Space Telescope Science Institute (STScI), Balti- 
more, Maryland 

Platforms and Operating Systems 

Each of these nodes above has important astrophysics 
catalogs for which it has principal responsibility. In gen- 
eral, these catalogs are maintained in different types of 
DBMS’s on different types of machines, each of which 
runs a unique operating system. Components of the 
ADS Core Services will be resident on a server at each 
node and connected by the ADS Message Passing Ser- 
vice software. (See the ADS Primary Nodes Compatibil- 
ity Requirements Document for a more detailed descrip- 
tion of the hardware interface.) The mapping of services 
to servers in the ADS is unconstrained: some servers si- 
multaneously provide several (simple) services while some 
(complex) services are segmented across several servers. 
In addition, the numbers and kinds of services that can 
be mounted on the ADS are also unconstrained. 
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Physical/ Logical Organization of Representative 
ADS Services. 


Nodes and Sites 

The ADS will be composed of Primary and Sec- 
ondary Nodes, an Administrative Node, and User Sites. 

An ADS primary node is defined as a facility which 
assumes primary responsibility for the provision of a 
unique service through the ADS infrastructure. This ser- 
vice can involve the provision of basic mission- specific 
data, as would be the case for a mission science support 
center fike.IUE, or for the provision of an operational ser- 
vice for remote access such as the IP AC- supported NASA 
Extragalactic Database (NED). 

A Primary Node assumes the responsibility for user 
support, maintenance of user services, data, and appro- 
priate documentation it provides via the ADS. Many dif- 
ferent kinds of services may be offered by primary nodes 
in the future, such as access to data archives or use of 
specialized processors or software. 

A Secondary Node is not responsible for user sup- 
port or for maintenance of data or service provided by 
the node. Its role is to provide local or regional copies of 


data or services. Provision for such copies should allevi- 
ate the load on the primary nodes and. greatly improve 
the responsiveness and reliability of the system. 

The ADS will also maintain an administrative node 
whose primary functions are to monitor the system (the 
user/service database, network throughput and connec- 
tivity, usage patterns, service availability, and security), 
and to serve as the top of the hierarchy that deals with 
user questions, problems and training. 

A site is defined as any physical location, outside of 
an ADS Node, where ADS-specific software exists (e.g., 
the User Interface, MPS, or DIAM) through which an 
investigator accesses the ADS or its services. 

Networking 

The first release of the ADS required network connec- 
tivity among the primary nodes and remote users (those 
not physically located at one of the primary nodes). This 
network connectivity will be furnished by the NASA Sci- 
ence Internet (NSI) which supports the TCP/IP protocol. 
While it is intended that the ADS will eventually support 
the DECNET protocol, this will not be the case for the 
first ADS release. 

User Scenario 

The prospective user of the Astrophysics Data Sys- 
tem should first obtain a copy of the ADS User’s Guide 
(contact the administrative node at the address at the 
end of this document), which will give specific details of 
how to obtain access to the ADS System. Generally a 
user will be assigned to one of the ADS Primary Nodes 
for user support. 

It is assumed that the user is a novice and is try- 
ing to do a very simple, well-defined task but one which 
requires access to multiple astrophysics data centers and 
their on-line databases. In this scenario, the user will 
locate and subset two independent datasets and then in- 
tercompare the results. Specifically, the problem is to 
correlate measurements of galaxies which have been ob- 
served to have both a significant infrared flux (indicative 
of a large amount of cold dust), and an X-ray or ultravi- 
olet flux (indicative of hot gas). 

The user first asks about the existence of 100 fx m 
(infrared) data, and ultimately finds his/her way to the 
IRAS Point Source Catalog. This user then wants to know 
if a subset of IRAS sources (e.g. galaxies that lie above 
30 degrees galactic latitude with 100 jxm flux greater 
than 10 Janskys and 60/100 fxm flux ratios indicative of 
temperatures less than 40K) have been observed in the 
X-ray (Einstein Catalog). 

Further, for those sources which were observed both 
in the infrared and with Einstein list the ones detected in 
IR and X-ray and plot the IR flux versus the X-ray flux 
for these objects. 

The specific steps are outlined below: 

Locating Infrared Datasets 

If we consider all the datasets potentially available in 



astrophysics (not just the ‘standard’ products of NASA 
missions), the potential size and diversity of these datasets 
become quite large. Without data location tools, locating 
the correct dataset for our investigation would be at least 
as difficult, if not more so, than the processing we will do 
once the data is found. In most cases accessing this data 
would be much more difficult than processing it. 

One of the primary services of the initial ADS im- 
plementation is the factor space documentation location 
method described above. With this we can pose a factor 
space query of the type “I am interested in long wave- 
length infrared measurements of galaxies, particularly 100 
pm measurements, in the form of catalogs. Color tem- 
peratures, specifically ones derived from long wavelength 
measurements, will be correlated with X-ray data to try 
and determine the relationship between cold dust emis- 
sion and that from hot gas”. 

The factor space query will return a list of docu- 
ments, some of which might be journal articles about sim- 
ilar research, some descriptions of catalogs or other data 
(e.g., images), some mission descriptions, etc. Somewhere 
near the top of this list is likely to be the description of 
the IRAS Point Source Catalog. Unless we have been 
distracted by some of the other documents, we will read 
this and decide that this catalog is indeed what we want 
for our IR data. By poking around the documentation re- 
lated to this catalog {a simple browse mechanism through 
our documentation) we also determine what fields in the 
catalog are important for our investigation. 

The documents used in the search are maintained at 
the same institutions that bear responsibility for the data 
itself. 

Locating the X-ray Datasets 

The X-ra,y data (in particular the Einstein database) 
would be found the same way. One of the rules of the ADS 
is that catalog datasets are not made accessible through 
the system until appropriate documentation is also on- 
line. 

Extracting the IR Data 

We have determined the correct catalog and even 
have some idea as to which fields are appropriate for our 
endeavor. The next step is to actually query the database 
where the data resides and get our subset. The basis for 
such queries is SQL, as described in the section on our 
DIAM (DAVIT)). Our query will look something like: 

select * from iraspsc where fluxl00>10 and 
fiux60<fiux!00 and (giat>30 or glat<-30) 

In addition to a direct SQL query capability, ADS 
provides a more intuitive query by example (QBE) mech- 
anism where the user puts constraint information directly 
into a template of the catalog in question. 

The infrared data of interest is located at the Infrared 
Processing and Analysis Center at the California Institute 
of Technology in Pasadena, California on a CDC Cyber 
mainframe in. the IM/DM database. 


Extracting the relevant X-ray Data 

To compare sources which both have an X-ray flux 
in the Einstein catalog and correspond to the sources ob- 
tained from our infrared query, requires the use of SQL 
for a database join. This is complicated somewhat by the 
need to potentially transform coordinates from one sys- 
tem or representation and then to perform the join based 
on spherical distance proximity. This process can also be 
performed using SQL directly or through the QBE mech- 
anism described above. 

Selection of the data must be done at the site where 
the data resides. However, the join process can be done 
at either data site or at the user’s local site. Optimiza- 
tion can be done to try and minimize the amount of data 
transfer but in practice the user usually wants to see the 
results of the two ‘selects’ before joining them and there- 
fore will transfer the data to the local site anyway. 

The X-ray data will be at the Harvard-Smithsonian 
Astrophysics! Observatory in Cambridge, Massachusetts 
in INGRES on a SUN workstation. 

Comparison of IR and X-ray Data 

Once the join has been completed, the result is a 
single table in which are combined IR and X-ray mea- 
surements. Proximity on the sky was the deciding factor 
in matching sources and so we may w'ell want to edit this 
table in a spreadsheet manner before proceeding. The fi- 
nal step in this example is simply to plot one column in 
this table versus another. 

Table processing and plotting will be performed lo- 
cally to the user. 

System Management Summary 

The ADS Program is currently managed from the 
Science Operations Branch, Astrophysics Division, NASA 
Headquarters, Washington, D.C. under Guenter Riegler. 
The ADS Project has been established at the Infrared 
Processing and Analysis Center which has also been des- 
ignated as the ADS Administrative Node. Dr. John Good 
is the ADS Project Manager and is responsible for the ac- 
tivities of the Administrative Node. 

Management of the overall ADS effort includes Sys- 
tem Development, System Oversight, and System Admin- 
istration. What follows is a summary of the more detailed 
material documented in the ADS Management Plan. 

System Development 

The design of the ADS is motivated by the fact that 
it exists in a dynamic science and information system en- 
vironment, and therefore it must be a dynamic system. 
Thus, even as the ADS is released, development contin- 
ues on Core Services, User Services, Network Connectiv- 
ity, and the addition of new nodes. System Management 
is responsible for technical oversight of prototyping re- 
search, selection criteria, development of standards and 
conventions, and all aspects of systems integration, test, 
and operation of new or revised ADS services. 
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System Oversight and Review Process 


To date, oversight of ADS development has been pro- 
vided by the ADS Working Group, under the leadership 
of James Weiss and John Nousek. When ADS becomes 
operational (and new nodes and sites are added to the 
system), the operation and continued development of the 
ADS will be overseen from both a users’ and a systems 
perspective by an anticipated hierarchy of committees. 
^ committees will review all proposals for ADS de- 
velopment, and will integrate, prioritize, and make policy 
recommendations on all aspects of the ADS Program. 

The Science Operation/Management Operations 
Working Group (SOMOW’G) has the highest oversight 
and review responsibility. As a matter of policy, the 
Science Operations Branch will make final selection of 
new ADS services, based on the results of the proposal 
and peer review process. For this purpose, an annual 
NASA Research Announcement (NRA) for the Astro- 
physics Software and Research Aids (ASRA) Program will 
be issued. 


System Administration 

The administration of the Astrophysics Data System 
is shared by NASA Headquarters, Astrophysics Division 
(Programmatic), the ADS Project Office/ADS Adminis- 
trative Node (Project), and the other primary nodes mak- 
ing up the ADS. The organizational structure, and defined 
roles and responsibilities are documented in Appendix A 
and the text of the ADS Management Plan, and in the 
ADS Primary Node Compatibility Requirements. 

. Development responsibilities include administration 
of both in-house and external service development con- 
tracts, certification of software, and software licensing. 

Operations Responsibilities include administration of 
maintenance contracts, system monitoring, system change 
control, and maintenance of system documentation. 

In addition, the administration - and coordination of 
all aspects of the review processes relevant to the ADS 
are the responsibility of the System Administration. 

Further information on the ADS can be obtained by 
contacting Dr. Good at 

Internet jcg@ipac.caltech.edu 
BITnet jcg%ipac@HAMLET.BitNet 
Telemail [JGOOD/NASAJNASAMAIL/USA 
uucp (cit-vax,trwrblcsula-ps)!ipac!jcg 

SPAN ROMEO:: “jcg%ipac n 

TEL: (818) 584-2939 
FAX: (818) 584-9945 

The work described in this paper was supported by 
the Jet Propulsion Laboratory, California Institute of 
Technology, under the sponsorship of the Astrophysics 
Division of NASA’s Office of Space Science and Appli- 
cations. 
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